llms: extract common llms errors to shared declaration #925
Conversation
|
Looks like the ci lint wasn't run before these files made it into main. I'm working on fixing them all now. |
…iables for golangci
…error check for golangci
|
CI is now passing. |
…tCommonLlmsErrorsToSharedDeclaration
|
@tmc I resolved conflicts with main for this and ensured that the linter is happy in the |
|
Thanks so much, this ia great to see. |
llms/errors.go
Outdated
| import "errors" | ||
|
|
||
| var ( | ||
| // ErrEmptyResponse is thrown when an LLM returns an empty response. |
There was a problem hiding this comment.
"thrown" isn't exactly the right language in Go,
There was a problem hiding this comment.
@tmc Fair. I'll change it to "is returned"
|
I wonder if llms is the right place to put the errors, I don't love the new source dependency on what is already a pretty large package implies. I don't have a better suggestion. @eliben do you have an opinion here? |
|
@tmc I have the same concern. It feels weird to have a root level errors package since the exported types are directly related to the LLMs. But it doesn't have to be. But it would probably also feel weird to have a root level errors package with just any and all exported errors in it. Very open to suggestions. |
I don't see the advantage of this approach - what's the motivation here? How are llm-unique errors going to be represented? |
PR Checklist
memory: add interfaces for X, Yorutil: add whizzbang helpers).Fixes #123).golangci-lintchecks.This addresses the comment Travis made in this PR I previously made. It specifically extracts the ErrorIncompleteEmbedding error and the ErrorEmptyResponse error used in the files in the
/llmsdirectory.I specifically targeted these errors because they're the ones I encountered using LangChain Go, there is still more work to be done in consolidating all of the other potentially shared errors.